I think if we are going to deprecate type comments we will absolutely need to provide a switch to let folks silence this message. Based on the primer output, it seems (expectedly) that the usage of type comments are pervasive in some code bases. These code bases should be allowed to ignore this deprecation for now. I also think if we are going to deprecate type comments loudly we should link from the deprecation message to a page in the documentation about how to migrate a codebase using type comments to annotations automatically (or at least, mostly automatically). This page should mention things like the libcst codemod https://libcst.readthedocs.io/en/latest/codemods.html#libcst.codemod.visitors.ApplyTypeAnnotationsVisitor

We should probably start with a new opt-in error code about type comments and explaining that we are planning to (soft) deprecate type comments eventually.

I'm working on a new parser for mypy and it doesn't yet fully support type comments, but it may be worth it to continue to support them still in the future, if many old type comments are still around. I think I can add full support for type comments to the new parser, it's just some extra work.

We might require some flag to even parse type comments at some point, but this would be a backward compatibility break.

I am fine with opt-in errors, but strongly against on-by-default errors for this. I think there are ways we can spend our churn budget that are better for users.

Happy to help with parser work (including adding support for type comments)!

The new parser is being developed here: https://github.com/mypyc/ast_serialize

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅